@akeeste this is ready for review

@ssolson Overall the structure of this PR looks good, but I found many differences in the specific module dependencies. From what I see in each module, we should have the following module-specific dependencies:

wave = [
    "scikit-learn>=1.5.1",
    "statsmodels>=0.14.2",
    "netCDF4>=1.7.1.post1",
    "pytz",
    "NREL-rex>=0.2.63",
    "beautifulsoup4",
    "requests",
]

tidal = [
    "netCDF4>=1.7.1.post1",
    "requests",
]

river = [
    "netCDF4>=1.7.1.post1",
    "requests",
]

dolfyn = [
    "h5py>=3.11.0",
    "h5pyd>=0.18.0",
    "netCDF4>=1.7.1.post1",
    "cartopy",
]

power = [
    
]

loads = [
    "fatpack",
]

mooring = [
    
]

acoustics = [
    
]

qc = [
    "pecos>=0.3.0",
]

utils = [
    "pecos>=0.3.0",
]

I also suggest that we alter tidal.performance to only import dolfyn.VelBinner instead of the entire dolfyn module so that it will not require all of the other DOLfYN dependencies.

The main item missing here is bottleneck, but I can't find where that is being used.

Adam great catch. Based on your review I decided to implement a test for each pip optional dependency where the tests for that module need to pass. Having some trouble with http requests that are delaying this from passing but I believe the lazy loading of modules is what we need to get this working. I don't expect the API to accept the data request until tomorrow at this point to get the tests passing.

Current Issue

The dolfyn module has become a critical dependency for several other modules (tidal, river, loads, mooring) through its coordinate transformation functionality. This creates a tight coupling where:

1. Any module that imports dolfyn (directly or indirectly) requires cartopy
2. I just added a lazy loading cartopy in dolfyn as a temporary fix that:
   • Only works because we know exactly where cartopy is used
   • Could break if new dependencies are added to dolfyn in the future
   • Doesn't address the fundamental architectural issue of tight coupling

Given the current architecture, the pip selective dependency installation approach may not be the best solution. We need to discuss if we want to move forward with this through a Longer-term refactor to the codebase by creating clear boundaries between modules by implement dependency injection for shared functionality

This would allow for true module independence and more flexible dependency management in the future.

dolfyn.adp.discharge.discharge() is the DOLfYN function that is used across MHKiT and should be moved to mhkit.utils in the future so that it can be accessed across MHKiT more easily, eliminating the tight coupling between DOLfYN and the other MHKiT modules

One more comment: it would be greatly preferred if users could just use pip install mhkit to get all dependencies using a typical installation method. @akeeste look into this during a final review of this PR

I dug through the pyproject.toml documentation but could not find a way to additionally allow pip install mhkit to function the same way as pip install mhkit[all]. Conda install can still be a simple method for users while the pip install allows for more advanced workflows. This is acceptable for now and we can change later on if required. We need to update the install instructions on our documentation.

The error message in mhkit/__init__.py for known modules however is never reached to inform the user how to install the optional dependencies. I will rework this before merging. I also think that utils should be a core dependency since its common functionality that many MHKiT modules use